COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002			Display-Oriented Editors for Computers
C00022 ENDMK
C⊗;
		Display-Oriented Editors for Computers

It seems desirable to review the general field of display-oriented editors for
interactive computers in view of the increasing use of such editors. There is a
growing development of many different editors that differ from each other, often
in only rather minor ways.  It is hoped that this review will prevent some
needless duplication of effort and perhaps lead to a degree of standardization.

Greater attention will be given to the ETV (or E for short) editor in use at the
Artificial Intelligence Laboratory at Stanford University than to others, but
this paper is in no sense a manual for this particular editor.  ETV is, perhaps,
one of the older page-oriented editors and it has been subject to rather
continuous development for more than five years. It does possess a number of
fairly unique features that might be of interest to others.  Also, many
desirable features that were first introduced in editors on other computers have
been shamelessly copied and made a part of this unified system.

		Basic Requirements

It may be usefull to first list some of the more important functions that a
display-oriented editor should ideally perform.

These functions are:

1) The editor should provide all of the conviences of a typewriter and in
addition it should be possible to over-type characters at will or to
insert or delete characters from any part of any line with the changes being
instantly shown.

2) The text that is being edited should be displayed continuously a page at a
time and one should be able to move from line to line, from page to page
and from file to file, all without leaving the editor and without losing
a record of where one came from.
If it is not possible to display a complete page then at least a
window-full of text should be shown and one must be able to move the window
around on the page.

3) Simple commands should allow one to attach selected portions of the text (or
copy and attach the copied portion) and then to move this attached portion
around on the page, to a different page in the same file or to any desired page
in any other file available to the user.  The ability to move text from
one file to another with ease and without leaving the editor is a most
desirable feature.

4) Having entered a file and having switched to some other file, it
should be possible to return to the earlier file without having to retype the
entire file name.

5) It should not be necessary to bring an entire file into high-speed memory
in order to edit it.  Paging systems may provide this function automatically
but it can and should be implimented on non-paging systems and in this case some
form of free-storage management should be provided so that the memory requirements
will be adjusted automatically to allow for differing page sizes.

6) As a further means of minimizing the fast-storage requirements, the ediitor's
code should be written as sharable code with only a small amount of storage reserved
for the individualized need of each user.

7) The editor should be easy to use. It should be fast and it should not
make any undue demands on system.
There are two aspects to speed, the one relating to the number of key strokes
demanded of the user, and the other relating to the internal opertion of the
program.  Speed in user operations requires that most commands be
limited to a single key stroke.
There are two ways of achieving fast internal operation that are so
effective as to be almost requirements in their own right. These are:
	a) The line-editor functions should reside in the operating system itself,
with space provided to hold each users current line whether or not his job is
currently in high-speed storage or not, and with service provided in a separate
system time slot so that editing can continue without requiring any action on
the part of the user's job during the editing of a single line of text.  Only
when the end of the line has been signalled, either by a carriage return or by
any one of several activating commands which then require that the user's job be 
run.
	b) A distinction should be drawn between the back-up copy of the file
being edited and the in-high-speed-memory copy.   Changes in the
high-speed-memory should not be reflected in changes in the back-up copy until such
time as they become necessary (if one goes to a different page or switches files)
or until such updating is specifically requested.

8) Search and substitution facilities should be provided so that the user can
quickly find any or all occurances of a specified string of characters and can,
if he wishes, substitute any other desired string for one or for any desired
number of the occurrances of the searched-for string.

9) Simple justifying, line filing, indenting and centering functions should be
provided.  It is usually not necessary to provide very elaborate publication
editing facilities as they needlessly burdon the editor code with functions
that are better performed by speciallized editors designed specifically for
this purpose.

Of course, it may not be practical to meet all of these requirements on a small
computers without sacrificing other desirable properties but, to the extent
possible, certain functions are highly desirable.  When there are conflicting
requirements that cannot all be met, then the specific uses to which the editor
is to be put will dictate the choice that will have to be made and as a result
there is ample justification for many differet kinds of editors.  In any case,
people will differ as to their assessment of the relative importance of the
different requirements and the "not invented here" effect still governs.

The author's personal views and the specific requirements that obtain at the
Stanford University A.I. Laboratory are the basis for the order in which the
above requirements are listed.  We have met these requirements in certain ways
that may be somewhat specific to our particular computer but which are believed
to be worth mentioning.  These additions will be discussed now.


1) Typing convenience.

   We feel that the use of permanently-displayed line numbers is
inconsistant with normal typing practice and should be avoided.  Storing line
numbers with every file is very wastful of storage space and shoould be avoided
this reason alone.

   We do allow lines to be identified by there relative position on the
page, and one may move to any desired line by a number specification.
These line numbers are not perminently assign to any specific line of
text, but change with every line insertion or deletion.  As many as 23
specific lines in each file may, however, be MARKED, that is, associated
with a reference numbers which do remain attached to the specified
lines.  By so marking lines in advance, one has most of the advantages
of line numbers without any of the disadvantages.

Information as to the numbers associated with the line currently being
edited and the top line on the window is contiuously displayed to the
user.  As a matter of fact, we go further and also allow one to move the
arrow (that points to the line to be edited) to any desired line in
terms of its position on the window, should this be more convenient at
the time.

2) Continuous display.
3) Attaching and moving blocks of text.
4) File switching.
5) Paging.
6) Shared code.
7) Speed.
   Simple commands (hopefully single character commands typed with a control key
to indicate to the computer that it is a command and not text) shold move the
window up and down on the page and should replace the current page with any
other desired page.  An alternative to the use of control keys on terminals
which are limited to six or seven bit codes is to reserve certain characters as
mode switching commands and to use these characters to indicate that one is
typing a command rather than text.

As an aside, most of the terminals used at the Stanford A.I. Laboratory have two
control keys, a full 128-character character set, and transmit 9 bits to the
computer.  As a result, we can and do assign special commands to most of the
normal letters and to many of the Greek letters that are in our character set
(using one or the other or both of the control keys to indicate that
it is a command).

8) Search and substitution.
9) Justification.

THE MATERIAL THAT FOLLOWS IS REDUNDANT AND SHOULD BE CULLED FOR IDEAS THAT
ARE NOT PROPERLY COVERED ABOVE.

   It should be possible to move from file to file without leaving the editor
and without losing a record of the files previously edited, including data as
to the location of the last line edited and possibly of other lines that have
been specially marked.  The editor should assign numbers to the files as they
are entered, it should display a list of the numbers and the names of the
associated files on request and one should be able to return to one's former
place in any desired previous file by typing the assigned number and a simple
command character.

4) It should be possible to attach portions of the text and to move these
portions around, on the current page, to other pages in the same file or
to pages in any other file available to the user.  The ability to move text
from one file to another with ease and without leaving the editor is a most
desirable feature.

5) It should be possible to edit a file with only one page of the file being in
the computer's memory at any one time.  This requirement can be met
automatically on page oriented computer systems but it can and should be
implemented on any on-line computer system.  This requirement removes any
artificial requirements on the permitted length of files, it minimizes the
memory requirements for the editor, and it greatly increases the operating
speed.

6) As a further refinement, the editor should provide some sort of free storage
management that allows the fast memory requirements to be increased and deceased
as required by the size of the current page of text.

7) The editor's code should be written as sharable code with only a smaller
amount of high speed memory assigned to each user.

8) The editor should be fast and should not make any more demands on the
system than are absolutely necessary.  In addition to the speed that can be
achieved by carefull programming there are two techniques that greatly reduce
the time consuming demands that the editor places on the system

The first of these is to have a special line editor within the system which
handles all users regardless of the current status of their jobs (in particular
even when their job are swapped out of high speed memory) and which does this
during system-controlled time slots.  When the end of a line is indicated by the
typing of a carriage return or some other activating character, then and only
then is it necessary for the users job to be in high speed memory and for the
contents of the system line-editor to be written into the users individual
area.  One can, of course, lose the current alterations to the current line
should something happen to the system during the time the line is in the line editor
but, by way of compensation, one can void the current alterations by a simple
command at any time prior to typing a carriage return or other activating
character should one decide that the editing is being done wrongly.

We have given some thought to an extension of this idea by having a system
page-editor or perhaps a system window-editor, but this would require the
perminant assignment of a much larger area in high-speed core for each user than
is required for a line-editor.  As currently implemented at SAIL the line editor
assigns to each user enough space for 140 characters of text plus a few words
for contol information.

A second method of minimizing the demands on the system is to update only the
fast-memory record of the page being edited on leaving the system line editor.
The slower operation, that of updating the permanent record is then done only by
those specific commands that are assigned this updating function. This method of
operation introduces a hazard in that there is the danger that the more recent
additions or alterations to a page can be lost should the system fail
catastrophically before one has had time to save the page.  This is ofset to
some extent by a not inconsiderable advantage in tha one can undo the effects of
incorrectly made alterations to the page,if they are noted in time, by giving a
command to rewrite the high-speed record of the page from the back-up store.

9)